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PREFACE 


This  document  is  a compilation  of  separately  prepared,  but 
interrelated,  reports  which  discuss  aspects  of  raster  image 
processing,  primarily  as  they  relate  to  a standard  tiling  scheme 
being  developed  to  support  the  interchange  of  large  raster 
images . 

This  document  was  prepared  in  support  of  the  Department  of 
Defense  (DoD)  Computer  Aided  Logistic  Support  (CALS)  Program 
under  an  Interagency  Agreement  between  the  National  Institute  of 
Standards  and  Technology  (NIST)  and  DoD.  The  objective  of  the 
CALS  Program,  a multi-year  effort,  is  to  integrate  the  design, 
manufacturing,  and  logistic  functions  through  the  efficient 
application  of  new  and  emerging  technologies.  A critical  step 
toward  achieving  this  objective  is  the  development  and  use  of 
standards  and  specifications  for  the  interchange  of  digital  data. 
NIST's  role  in  this  effort  is  to  assist  DoD  in  the  development  of 
military  specifications  and  to  help  expedite  the  development  and 
enhancement  of  national  and  international  hardware,  software,  and 
data  interchange  standards. 

A number  of  reports  relating  to  raster  graphics  were  developed  in 
support  of  the  DoD  CALS  effort.  The  reports  were  prepared  by 
members  of  an  ad  hoc  Tiling  Task  Group  (TTG)  composed  of 
government  and  industry  representatives  and  chaired  by  NIST.  The 
TTG  with  the  aid  of  ANSI/X3V1  members  has  developed  and  submitted 
to  ISO  an  addendum  to  part  7 of  ISO  8613,  Office  Document 
Architecture  (ODA)  and  Interchange  Format.  This  addendum  will 
allow  vendors  to  deliver,  and  the  government  to  accept,  digital 
technical  data  in  lieu  of  paper  and  film.  Upon  approval  of  the 
addendum,  the  Document  Application  Profile  for  the  Interchange  of 
Large  Format  Tiled  Raster  Documents,  described  in  this  document, 
will  be  considered  for  publication  as  a Federal  Information 
Processing  Standard  (FIPS) . 

Raster  graphics  or  image  processing  allows  the  user  to  capture, 
maintain,  manipulate  and  distribute  pictorial  information  in  a 
digital  format.  Such  digitized  images  include  engineering  and 
architectural  drawings,  diagrams,  photographs,  pictures, 
fingerprints,  and  other  pictorial  material.  The  first  report  of 
this  document  describes  existing  standards  that  support  raster 
graphics  within  office  document  processing  environments.  The 
remaining  reports  in  this  document  concentrate  on  the  development 
of  standards  required  to  support  the  interchange  of  large  format 
images.  Their  focus  is  on  a standard  tiling  scheme  to  be  used 
for  applications  supporting  the  interchange  of  large  format 
engineering  drawings.  This  scheme  provides  a method  for 
subdividing  a large  raster  graphics  image  into  subelements  called 
tiles . 
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The  five  reports  composing  this  document  describe  specific  areas 
of  raster  graphics.  Each  is  intended  for  a different  audience. 
The  first  report  provides  the  reader  with  a brief  introduction  to 
raster  graphics  and  the  current  standards  used  to  support  raster 
graphics  applications.  The  second  provides  the  reader  with  a 
non-technical  overview  of  the  tiling  scheme.  The  third  report 
describes  the  user's  requirements  for  tiling  that  were  identified 
by  the  TTG.  The  fourth  report,  a Document  Application  Profile, 
presents  information  about  all  the  attributes  pertaining  to  a 
tiling  application.  The  fifth  report  is  a proposed  addendum  to 
an  ANSI  standard  which  is  required  to  support  the  tiling  scheme. 
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RASTER  GRAPHICS: 

BASIC  CONCEPTS  AND  STANDARDS 

Frankie  E.  Spielman 


Section  I 


RASTER  GRAPHICS; 

BASIC  CONCEPTS  AND  STANDARDS 


Raster  graphics  provides  the  capability  to  process,  store,  and 
exchange  images  in  a digital  format.  This  technology  will  play  a 
significant  role  in  future  systems  development  as  we  move  toward 
the  elusive  goal  of  the  paperless  office  and  work  environment. 

Raster  graphics  has  been  used  for  several  years  to  exchange 
documents  by  facsimile.  More  recently,  elements  of  the 
Department  of  Defense  (DoD) , specifically  the  Army  and  Air  Force, 
have  started  using  this  technology  to  store  engineering 
documents.  The  Navy  and  Defense  Logistics  Agency  (DLA)  are  also 
in  the  process  of  procuring  systems  using  raster  graphics  to 
store  engineering  documents.  Additionally,  DoD  future  plans  call 
for  the  exchange  of  engineering  documents  using  raster  graphics 
technology.  Similarly,  the  Patent  Trademark  Office  has  started 
digitizing  and  storing  a portion  of  their  patents  using  raster 
graphics,  thus  making  them  available  for  on-line  review.  Raster 
graphics  technology  is  absolutely  necessary  for  applications  that 
interchange  and  store  pictorial  data  such  as  photographs  and 
logos . 

Raster  graphics  is  a method  of  representing  a two-dimensional 
image  by  dividing  it  into  a rectangular  two-dimensional  array  of 
picture  elements  (pels) . Each  element  of  the  pel  array  comprises 
data  indicating  the  color  and  the  brightness  of  the  corresponding 
picture  element  of  the  image.  To  produce  a raster  image  from  an 
existing  document,  the  hard  copy  paper  or  microfilm  media  must  be 
processed  through  a raster  scanning  device. 

The  data  which  determines  the  image  of  a pel  specifies  one  of  two 
states,  named  "set"  and  "unset."  The  set  state  is  used  to 
identify  the  foreground  color  and  the  unset  to  identify  the 
background  color.  In  black  and  white  images,  the  foreground  is 
represented  by  a "1"  and  background  by  a "0."  For  reproduction 
on  paper,  the  background  color  will  normally  be  white  and  the 
foreground  color  black.  The  array  is  often  referred  to  as  the 
bit-map  image. 

In  the  electronic  data  capture  and  conversion  of  existing  images 
to  digital  form  by  an  optical  scan  process,  the  scanner 
superimposes  an  imaginary  grid  or  raster  over  the  image  to  be 
scanned.  Each  of  the  grid  squares  represents  an  individual  pel 
in  the  pel-array.  Scanning  is  performed  from  left  to  right  along 
each  line  beginning  at  the  top  of  the  page.  The  scanner 
evaluates  each  pel  and  assigns  a corresponding  binary  value  of 
"0"  for  mostly  white  or  "1"  for  mostly  black. 
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The  dimensions  of  the  array  or  bit-map  are  determined  by  the  size 
of  the  document  or  image  being  represented.  The  image  detail 
that  can  be  illustrated  is  dependent  upon  the  resolution  density 
of  the  raster  grid.  The  resolution  density  is  the  specific 
number  of  pels  per  inch  which  is  normally  the  same  for  both 
directions  of  the  image  dimensions.  Image  detail  can  be  improved 
by  increasing  the  grid  density  but  this  also  increases  the 
storage  and  data  processing  requirements.  Consequently,  there  is 
a trade-off  between  the  image  detail  required  for  the  application 
and  the  costs  associated  with  the  higher  density  requirements. 

One  of  the  costlier  aspects  of  raster  graphics  processing  is  the 
large  amount  of  data  generated  by  the  process.  For  example,  the 
actual  letters  "Me,"  as  illustrated  in  figure  1,  require  only  16 
bits,  or  two  bytes,  to  represent  using  ASCII  character  coding. 
The  bit-map  image,  as  shown  in  figure  2,  requires  a total  of  1260 
bits,  or  158  bytes,  to  represent  these  same  two  letters  in  a 
raster  image  format.  To  help  reduce  the.  storage  requirements, 
there  have  been  several  encoding  schemes  developed  to  compress 
raster  data.  In  the  world  of  facsimile  transmission,  the 
International  Consultative  Committee  on  Telegraphy  and  Telephony 
(CCITT)  Recommendation  T.4  (Group  3)  is  currently  used  for 
compressing  the  documents  during  transmission  [CCITT84a] . It  is 
anticipated  that  future  systems  will  use  the  CCITT  Recommendation 
T.6  Group  4 compression  algorithm  [CCITT84b] . DoD  Military 
Standard  1840A  stipulates  the  use  of>  CCITT  Recommendation  T.6 
Group  4 as  the  DoD  standard  to  be  used  for  the  interchange  of 
raster  data  between  DoD  installations  and  their  vendors 
[MILSTD87].  Compression  ratios  can  typically  range  from  10:1  to 
50:1  depending  upon  the  complexity  of  the  image.  In  a report 
completed  for  DoD,  the  average  compression  ratio  using  a modified 
Group  4 compression  algorithm  on  40  DoD  images  from  Army  and  Air 
Force  data  repositories  was  22:1  [AITI87]. 

Raster  graphics  images  can  be  integrated  into  office  documents 
through  the  use  of  International  Standard  ISO  8613,  Office 
Document  Architecture  (ODA)  and  Interchange  Format  [IS088].  ODA 
provides  for  open  interchange  of  structured  compound  documents 
containing  text,  vector  graphics  and  raster  graphics.  It 
provides  the  rules  for  partitioning  and  organizing  (structuring) 
the  document  and  the  encodings  for  this  structure  using  Abstract 
Syntax  Notation  One  (ASN.l).  ASN.l  is  specified  in  ISO  8824  and 
ISO  8825  [IS087a,  IS087b] . 

A standard  is  being  developed  which  provides  a scheme  for 
subdividing  a large  raster  graphics  image  into  non-overlapping 
regions  called  tiles.  This  scheme  provides  a format  that 
supports  operations  on  portions  of  a large  image  without 
requiring  other  portions  of  the  image  to  be  accessed.  It  also 
allows  parallel  compression  and  decompression  of  the  individual 
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tiles.  DoD  has  specified  the  use  of  tiled  raster  graphics  in 
MIL-R-28002,  the  DoD  standard  for  the  delivery  to  the  Government 
of  raster  graphics  data  in  digital  form  by  contractors 
[MILSTD88].  The  remainder  of  this  document  describes  the 
requirements  for  the  evolving  tiling  raster  graphics  standard, 
which  will  be  an  addendum  to  ISO  8613,  ODA/ODIF,  Part  7. 
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Figure  1 - The  Raster  Scan  Process 


NOTE;  The  boundary  of  each  pel  is  directly  adjacent  to  its 
neighboring  pel  without  any  space  between  them. 
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Figure  2 - Raster  Data 
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Tiling  in  Large-Format  Raster  Documents 


INTRODUCTION 

When  ancient  builders  looked  for  ways  to  build  their  residences 
or  their  tombs  permanently  and  colorfully,  they  turned  to  ceramic 
tiles.  A tile  was  a manageably-sized  chunk  of  technology  with 
all  the  right  properties.  In  the  emerging  large  document  raster 
field,  some  rather  daunting  systems  problems  can  similarly  be 
managed  by  the  divide  and  conquer  strategy  of  tiling.  In  this 
case  the  chunks  are  pieces  of  an  electronic  image  rather  than 
baked  clay,  but  the  principle  is  the  same:  dissect  the  problem, 
reduce  it  to  manageable  elements  and  all  manner  of  advantages 
follow. 


WHAT  IS  TILING  ? 

The  Latin  word  for  tile  comes  from  the  verb  "to  cover."  Tiling 
is  a means  of  breaking  an  electronic  image  into  pieces  by 
completely  covering  the  image  plane  with  many  identically  shaped, 
perfectly  interlocking  regions.  Rectangles  or  squares  are  the 
most  obvious  and  useful  such  regions,  though  an  entire  branch  of 
mathematics  has  arisen  to  identify  others. 

Tiling  allows  a large,  seamless  bit-mapped  image  to  be  cut  up, 
manipulated  in  some  fashion,  and  then  sewn  back  together.  It 
essentially  only  affects  the  storage  order  of  pels.  Normally  all 
the  pels  of  an  image  follow  one  another  in  a left  to  right,  top 
to  bottom,  raster  fashion.  Tiling  results  in  the  storage  of  one 
tile  after  another;  only  within  a given  tile  does  the  raster 
ordering  of  pels  occur. 


WHY  TILE  ? 

Craftsmen  called  upon  by  their  ruler  to  ornament  his  palace 
12,000  to  18,000  years  ago  used  ceramic  tiles.  Why?  They  were 
small  enough  to  be  easily  manufactured,  handled,  and  applied. 

When  building  a raster  image  handling  system,  what  are  some  of 
the  things  we  want  to  do  with  an  image?  How  can  tiling  help? 

Storing  the  image  is  the  most  immediate  problem.  Today's  high- 
speed scanners  can  produce  data  at  a rate  and  of  a quantity  well 
beyond  the  abilities  of  the  average  mass  storage  architecture. 
Compression  is  clearly  needed  to  alleviate  both  storage  bandwidth 
and  storage  size  difficulties. 

The  existing  compression  standard  for  facsimile,  known  as  CCITT 
Group  4 or  (more  precisely)  T.6  encoding,  is  well  suited  to 
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binary  images.  While  some  other  schemes  are  being  evaluated, 
this  method  still  holds  the  central  role  in  all  binary  image 
standards  work  and  will  dominate  the  raster  image  products  of  the 
1990 ' s. 

It  is  a statistically-based  technique,  however.  This  means  it 
(a)  is  not  guaranteed  to  produce  a result  smaller  than  the 
original,  and  (b)  is  going  to  have  wild  variations  in  processing 
speed.  Systems  designers  are  fond  of  more  predictable  elements: 
worst-case  design  assumptions  will  result  in  high  cost,  but 
design  to  the  average  case  will  result  in  systems  that  fail. 

Can  tiling  help  with  these  two  problems?  Yes,  indeed,  and  in 
much  the  same  way  that  ceramic  tile  makes  a building  problem 
easier. 

Tiling  helps  with  the  storage  size.  The  fact  that  T.6 
compression  on  average  produces  data  sets  10  to  20  times  smaller 
is  beneficial  but  covers  up  a rather  nasty  fact.  For  significant 
portions  of  a busy  image,  it  can  actually  neoativelv  compress 
(i.e.  enlarge)  the  image.  Well,  someone  might  say,  why  not 
simply  take  the  entire  uncompressed  image  in  place  of  such  a 
poorly  compressed  image?  We  could,  but  then  we  lose  the  benefit 
of  the  high  compression  achieved  in  the  border  or  non-busy  areas. 
If  we  tile,  we  can  decide  on  a tile-by-tile  basis  whether  to  use 
the  compressor's  result  or  to  stay  with  the  original  bit-map 
image  of  that  tile. 

This  also  cures  a more  subtle  difficulty  with  the  untiled  case: 
even  if  the  overall  image  would  have  come  out  reduced  in  size, 
the  momentary  flood  of  data  from  a busy  region  could  overwhelm 
busses  or  storage  devices  and  cause  a scan  or  print  to  abort. 
The  only  way  around  this  is  to  have  a full  image  buffer  before 
the  compression  module.  Even  worse,  this  would  have  to  be  a dual 
buffer  for  systems  which  are  pipelined  to  allow  scanning  and 
compression  to  go  on  in  parallel.  This  buffer  is  in  addition  to 
the  full-image  buffer  required  by  both  methods  after  the 
compressor  (for  those  documents  which  compress  very  poorly). 
Tiling  permits  us  to  substitute  the  bit-map  of  the  tile  in  place 
of  any  tile  which  would  overwhelm  our  system  with  a temporary 
flood  of  data.  This  cures  the  storage  bandwidth  problem  without 
introducing  additional  expensive  full-image  buffers. 

Tiling  also  helps  with  the  processing  speed  problem.  The 
bandwidth  problem  just  discussed  is  a case  where  the  local 
variations  in  the  non-redundant  data  content  of  the  image  cause 
momentary  difficulties.  What  if  systems  considerations  require  a 
minimum  instantaneous  compression  or  expansion  rate  (e.g., 
averaged  over  the  time  required  to  handle  a small  buffer)?  For 
example,  a scanner. or  laser  printer  moving  too  fast  to  do  line- 
on-demand  would  need  this.  We  need  either  a very  fast  engine  or 
many  moderate  speed  engines  to  share  this  "deadline  burden." 
Since  the  T.6  algorithm  operates  by  reference  to  the  line  above 
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the  current  line,  it  is  not  possible  to  break  an  image  into 
multiple  pieces,  parcelling  out  the  work.  Tiling  essentially 
makes  many  smaller,  distinct  images  (at  some  small  penalty  in 
overall  compression)  from  one  large  one.  The  appropriate  level 
of  parallel  processing  can  then  be  applied  to  tackle  the 
throughput  need. 

Tiling  makes  it  easier  to  build  high-performance  integrated 
circuits  for  large  documents.  Just  as  it  would  be  difficult 
indeed  to  spread  an  entire  wall  with  clay  and  fire  it  as  one 
unit,  so  it  is  hard  to  design  a chip  for  any  width  image. 
Significant  speed  advantages  accrue  if  an  on-chip  reference  line 
memory  is  used,  but  some  assumptions  must  be  made  about  its  size. 
Competitive  pressure  and  market  realities  dictate  that  this 
memory  will  be  sized  with  small  documents  in  mind.  Tiles  allow 
such  integrated  circuits  to  be  used  on  arbitrarily  wide  images. 


HOW  TO  TILE 

What  shape  tiles  should  we  choose?  Rectangular  shapes  are  the 
most  sensible  from  an  implementation  point  of  view.  If  90  degree 
rotation  is  considered,  square  tiles  make  even  more  sense. 

To  tile,  we  need  to  create  a grid  of  the  appropriate  number  of 
square  tiles.  We  then  take  our  large-document  image  and  lay  it 
on  this  grid.  We  can  position  it  any  way  we  like  over  the  grid 
as  long  as  we  keep  it  orthogonal  and  within  the  outer  grid 
boundary.  We  then  define  the  area  within  the  tile  grid  which 
actually  contains  image  data;  it  will  likely  be  smaller  than  the 
enclosing  set  of  tiles  it  touches.  Some  portion  of  each  of  the 
tiles  on  the  outer  "ring"  of  tiles  may  in  fact  be  unused.  The 
portion  of  this  image  we  are  truly  interested  in  may  in  fact  be 
smaller  still  due  to  overscan. 

What  size  tiles  should  we  choose? 

At  first  sight,  the  size  of  ceramic  tiles  seems  to  have  been 
fixed  by  artistic  evolution  or  convention  to  be  (let  us  say)  4 by 
4 inches.  However,  analysis  shows  instead  that  material  and 
process  limitations  (e.g.  firing  temperatures,  vulnerability  to 
breakage,  etc.)  were  really  the  key  factors. 

Similar  considerations  govern  the  choice  of  a size  for  an 
electronic  tile.  We  do  not  wish  to  exceed  the  limits  of 
available  technology  or  even  to  be  pushed  up  to  the  (expensive) 
frontier. 

"Cooking"  an  electronic  tile  requires  it  to  be  stored  in  a fast 
static  RAM  memory  buffer.  The  largest  of  these  'with  a modest 
price  is  32K  bytes  or  256K  binary  pels.  This  corresponds  to  a 
tile  of  512  by  512  pels. 


II-3 


The  "cutting  up"  of  tiles  during  scanning  or  the  "stitching 
together"  of  tiles  during  printing  requires  buffering  up  an 
entire  row's  worth  of  tiles  before  playing  the  data  out  in  a new 
raster  order.  With  the  line  widths  encountered  in  some  large- 
format  raster  images,  a full  row  of  512  line  high  tiles  will  take 
a megabyte  or  two  of  dynamic  RAM,  again  available  at  a modest 
price . 

A quick  look  at  available  and  planned  compression/expansion  chips 
shows  them  all  capable  of  handling  a 512  pel  wide  tile.  Rotation 
of  that  size  tile  is  straightforward  both  in  hardware  and  in 
software.  The  branch  of  commercial  image  processing  that  grew  up 
around  television  camera  and  frame  grabber  technology  also  often 
uses  512  by  512  as  its  image  size. 

Once  a tile  shape  and  size  have  been  set,  what  other  elements  are 
needed  for  a tiling  scheme? 

1.  A description  of  the  number  of  tiles  present  lets  a 
program  reading  a tiled  file  reserve  a frugal  amount  of 
memory  for  that  purpose.  Whether  it  occurs  explicitly 
or  implicitly,  an  absolute  limit  to  that  number  lets  the 
programmer  make  further  simplifying  assumptions.  A 
limit  of  4096  tiles  is  more  than  sufficient  to  handle  a 
K size  (40"  by  143")  image  at  400  dots  per  inch  (dpi) 
with  one  inch  overscan. 

2.  A tile  index,  which  would  be  much  like  the  index  in  the 
back  of  a book,  only  more  likely  to  be  modified.  An 
index  allows  a specific  tile  to  be  found  directly, 
without  having  to  sift  down  through  a long  chain  of 
tiles  each  time.  An  index  allows  one  to  change  the 
ordering  of  tiles  by  simply  changing  the  pointer  to 
where  a tile  is  located  within  the  file.  A tile  index 
can  be  included  within  a file  format  as  an  application 
comment,  or  can  be  built  up  upon  the  first  encounter 
with  the  file.  Such  an  index  would  have,  for  each  tile, 
a content  offset.  The  offset  is  a the  distance  in  bytes 
from  the  beginning  of  the  index  to  the  beginning  of  the 
tile,  allowing  a program  to  go  directly  to  get  a given 
tile . 

3.  An  indication  of  where  the  actual  image  is  located 
within  the  tile  grid.  This  can  be  accomplished  by  a 
tiling  offset.  The  offset  would  be  the  coordinates 
within  the  first  tile  of  the  starting  corner  of  the 
actual  image.  The  true  image  size  will  in  general  be 
smaller  than  the  outer  dimensions  of  the  tile  grid. 
Because  most  images  will  not  be  exact  multiples  of  the 
tile  size,  so-called  "runt  tiles"  along  some  of  the 
edges  of  the  tile  grid  will  result.  These  partially- 
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used  tiles  will  exist  in  a ring  around  the  periphery  of 
the  other,  fully-used  tiles.  This  ring  will  be  at  most 
one  tile  wide. 

4.  A pair  of  points  marking  the  diagonal  corners  of  a 
rectangle  indicating  the  so-called  clipping.  This  is 
handy  for  after-the-fact  trimming  of  an  over-scanned 
image  to  indicate  which  portion  of  the  image  is  truly  of 
interest.  This  is  necessary  in  addition  to  the  tiling 
offset  discussed  above. 

A tiling  standard  for  large-format  documents  would  of  course  have 
to  support  all  the  common  and  anticipated  resolutions  (100  to 
1200  dots  per  inch)  and  sizes  (A  through  K and  A4  through  AO)  of 
images . 

Two  additional  pieces  of  information  are  necessary  to  process  the 
actual  tile  content.  Those  pieces  are: 

Tile  type.  The  tile  type  lets  the  application  program  know 
how  to  treat  the  tile  it  finds  there:  whether  to  expand  it 
or  leave  it  as  a bit-map.  The  tile  type  may  also  be  null 
foreground  or  null  background.  When  the  tile  is  of  one  of 
these  two  types,  no  actual  tile  content  will  follow  because 
it  is  unnecessary. 

Tile  position.  The  tile  position  tells  a program  where  to 
"paint”  or  render  the  tile  on  the  page.  Given  a tiling 
offset  (position  of  the  start  of  the  pel  array  in  the  first 
tile)  and  the  tile  dimensions,  the  position  of  each  tile  can 
be  calculated  if  not  explicitly  stored. 

SYSTEM  ARCHITECTURE 

Within  the  limits  of  the  available  technology,  ceramic  tiles 
evolved  to  become  a reliable  and  convenient  building  block.  They 
set  a size  scale  below  which  attention  was  not  required,  allowing 
a focus  on  a grander  scale. 

In  our  present  context,  that  grander  scale  is  called  systems 
design,  and  the  systems  of  immediate  interest  are  those  for  the 
management  of  electronic  images.  In  large-document  image 
management  systems,  scanning,  compression,  quality  assurance 
inspection,  transmission,  storage,  editing,  expansion,  and 
printing  are  all  essential.  Tiling  can  be  enormously  helpful  in 
these  areas,  as  the  following  demonstrates: 

* Viewing  an  image  during  both  editing  and  inspection  can 
be  either  done  faster  or  performed  on  a lower-cost 
workstation  if  tiling  is  used.  If  a zoomed-back  view  of 
the  document  is  separately  stored,  there  is  no  need  to 
ever  expand  the  entire  image  into  a full-image  buffer. 
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since  8 megabytes  is  rather  expensive  (E  size  at  200  dots 
per  inch)  and  32  megabytes  more  so  (400  dpi)  , a systems 
design  which  allows  expansion  of  only  the  portion  of  the 
document  which  is  actually  being  displayed  can  save  a lot 
of  money.  Current  generation  displays  can  present  a 
full-resolution  view  of  about  six  512  by  512  tiles.  The 
new  generation  of  faster  compressor/expanders  can  easily 
keep  up  with  real-time  panning  on  the  screen,  i.e.  they 
can  compress  the  recently  modified  tiles  as  they  pass  off 
the  screen,  and  expand  the  new  ones  sliding  into  view. 

* Raster  editor  software  can  be  written  to  take  advantage 
of  tiling  techniques.  For  example,  in  an  editing  station 
only  the  modified  tiles  need  be  written  back  to  the  file. 
They  can  be  tagged  onto  the  end  of  the  other  tiles  and 
the  tile  index  changed,  without  having  to  re-order 
everything.  If  an  aperture  card  scanner  produces  an 
image  with  a different  orientation  than  that  desired  by 
the  editor  and  user,  the  tile  index  takes  care  of 
describing  the  proper  lef  t-to-right , top-to-bottom 
ordering  of  the  tiles  even  though  their  physical  ordering 
in  storage  will  still  be  that  which  was  convenient  for 
quick  handling  during  the  scan.  Then,  only  as  the  editor 
"touches"  tiles  do  they  need  to  be  actually  rotated  90 
degrees.  At  the  time  of  interchange,  however,  all  the 
remaining  tiles  would  have  to  be  rotated  and  placed  in 
the  proper  order.  The  editor  can  ship  tiles  off  to 
hardware  modules  to  have  rotation  and  other  tasks  such  as 
despeckling  or  scaling  performed. 

* Tiling  can  reduce  a network's  transmission  capacity  needs 

by  lowering  peak  demands.  When  a user  requests  a 

drawing,  the  storage  server  and  network  need  not  provide 
the  entire  image  at  once.  If  a separately-stored 
overview  is  available  (which  would  have  a small  file 
size) , it  would  likely  be  sent  first  along  with  the  index 
of  the  full-resolution,  tiled  image.  When  the  user 
identifies  a region  of  interest,  the  first  view's  worth 
of  tiles  would  then  be  requested  and  sent.  Then,  if  and 
when  the  user  begins  panning,  the  appropriate  tiles 
(perhaps  with  some  degree  of  anticipation)  can  be 
requested  incrementally. 

* In  a low-cost  environment,  tiling  could  allow  all 
compression  and  expansion  to  be  performed  by  a central, 
multitasked  server.  This  is  possible  because  tiles 
represent  well-defined,  distinct  tasks.  The  server 
could,  for  instance,  compress  a tile  for  a raster  editor 
which  just  experienced  a panning  event,  expand  a tile  to 
send  to  a laser  printer,  and  expand  a new  tile  for 
display,  all  "simultaneously."  If  the  server  were 
located  over  a network,  this  would  result  in  rather  low 
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performance,  since  half  of  all  the  data  would  be 
uncompressed.  If,  on  the  other  hand,  the  server  were 
located  on  a workstation  bus  or  the  Small  Computer 
Systems  Interface  (SCSI)  bus,  the  performance  would  be 
very  good.  In  either  case,  the  cost  advantage  of  sharing 
the  compression/expansion  function  among  several 
peripherals  is  clear. 

* The  quality  assurance  (QA)  function  is  an  important  one, 
particularly  when  the  electronic  image  will  replace  its 
paper  or  aperture  card  equivalent.  The  clipped  pel  array 
feature  can  be  used  at  a QA  workstation  to  indicate  via 
an  outline  the  area  out  of  a full  aperture  scan  where  the 
document  is  suppose  to  be  located.  In  the  likely  event 
that  the  card  was  out  of  specification,  the  operator  need 
only  move  the  outline  to  a more  appropriate  position.  If 
the  document  had  been  pre-tiled  and  compressed  by  the 
scanner  (and  tagged  with  a guess  at  the  active  area 
outline) , all  that  need  be  done  is  to  modify  the  field  in 
the  file  describing  the  clipped  area.  Later  automated 
processing  can  "white  out"  and  recompress  partial  tiles, 
discard  unused  tiles,  etc.  to  achieve  a smaller  size  or 
the  file  can  simply  be  left  as-is.  If  the  scanner  had 

not  compressed  or  tiled  the  image,  the  QA  workstation 
would  do  these  things  as  the  operator  signs  off  on  the 
scan. 

STANDARDIZATION  OF  TILING 

The  Tiling  Task  Group  was  formed  to  put  forward  a standard 
allowing  industry-wide  interchange  of  data,  lower  systems  costs, 
and  growth  of  the  large-document  raster  market.  The  hard  work  of 
many  people  made  that  a success. 

The  standardization  activity  has  produced  documents  which  fit 
into  the  scheme  defined  by  Office  Document  Architecture  (ODA)  and 
Interchange  Format.  ODA,  ISO  8613,  is  designed  for  the 
interchange  of  intelligent,  multi-media  documents.  To  slip  the 
tiling  scheme  into  this  mainstream  effort,  three  documents  had  to 
be  produced:  User  Requirements,  Content  Architecture,  and 

Application  Profile.  These  three  documents  were  derived  from  the 
Tiled  Raster  Interchange  Format  (TRIF)  working  documents  created 
by  the  Tiling  Task  Group. 

The  first  is  the  User  Requirements  document.  This,  quite 

logically,  answers  the  following:  Why  do  people  need  tiling? 

What  are  the  unique  requirements  of  this  class  of  user?  Why 

can't  they  use  what  already  exists?  What  are  the  motivating 

principles  in  the  ensuing  documents? 

The  second  document  is  a Content  Architecture  for  the  tiled 

raster  graphics  content  to  be  included  in  a document.  A content 
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architecture  is  the  "vocabulary"  of  concepts  used  to  express  a 
given  type  of  content  within  a document.  Fortunately,  ISO  8613, 
Part  7,  Raster  Graphics  Content  Architecture,  already  exists  to 
deal  with  raster  images.  The  new  concepts  required  for  tiled 
raster  graphics  have  been  included  in  a proposed  addendum  to  ISO 
8613  Part  7.  This  puts  all  large-document  raster  work  squarely 
into  the  smaller-document  and  facsimile  mainstream,  assuring 
compatibility  and  making  workstations  and  peripherals  capable  of 
handling  both  needs  more  easily. 

The  third  document  is  an  Application  Profile.  This  takes  the 
needs  identified  in  the  User  Requirements  and  tools  defined  in 
the  Content  Architecture  together  to  describe  a subset  which  is 
sufficient  to  the  application.  In  the  absence  of  the  application 
profile,  we  would  be  faced  with  a standards  problem,  i.e. 
guidelines  so  broad  and  all  encompassing  that  no  given  vendor 
would  choose  exactly  the  same  subset  to  implement  as  any  other 
vendor. 

Tiled  raster  graphics  has  been  specified  for  use  by  the 
Department  of  Defense  (DoD)  in  MIL-R-28002,  the  DoD  standard  for 
the  delivery  to  the  Government  of  raster  graphics  data  in  digital 
form  by  contractors. 
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Requirements  for  Tiled  Raster  Graphics 
Tiling  Task  Group 


Introduction 

This  document  outlines  the  user  requirements  for  tiled  raster 
graphics  that  were  identified  by  the  Tiling  Task  Group  (TTG) . 
The  TTG,  in  addressing  these  requirements,  has  sought  to 
establish  a conventional  way  for  implementing  tiling  in  large- 
format  raster  images.  This  document  describes  the  considerations 
and  reasoning  which  led  to  the  TTG  proposals.  These  proposals 
are  being  implemented  in  other  documents  including  an  addendum  to 
the  ISO  8613  Part  7 content  architecture  and  an  application 
profile. 

Background 

Interest  in  an  industry-supported  tiling  scheme  was  first 
expressed  at  a meeting  with  the  Department  of  Defense  on  April 
15,  1987.  A number  of  large-document  raster  equipment  and 
software  vendors  were  present  to  discuss  the  issue  of  image 
encoding  of  engineering  drawings  for  delivery  to  the  government. 
While  it  was  clear  that  the  majority  supported  encoding  schemes 
consistent  with  the  ODA/ODIF  work,  a remarkable  consensus  was 
spontaneously  expressed  that  an  additional  feature  was  needed: 
tiling. 

As  a result  of  that  meeting,  a task  group  composed  of  industry 
representatives  including  system  integrators,  peripheral 
manufacturers,  and  users,  as  well  as  government  representatives, 
assembled  in  an  open  forum  to  exchange  views  on  tiling.  This  ad 
hoc  group  (TTG)  concluded  that  development  of  an  interchange 
format  using  tiling  was  desirable.  Subsequently,  a number  of 
meetings  and  reviews  were  held  by  the  TTG  in  order  to  develop 
this  proposal. 

Purpose 

The  need  for  an  interchange  format  using  a tiling  scheme  arose 
from  a number  of  considerations  associated  with  handling  large- 
format  engineering  drawings  in  raster  format.  In  developing  the 
tiling  format,  issues  were  raised  and  evaluated  concerning  the 
usefulness  and  efficiency  of  tiling  as  a technique  for  handling 
large-format  raster  images  between  and  within  a wide  range  of 
systems.  It  was  generally  agreed  that  a tiling  scheme  could  be 
developed  that  would  receive  broad,  industry-wide  support. 


Therefore,  it  was  the  intent  of  the  TTG  to  recommend  a well- 
defined  scheme  to  foster  industry  adoption.  The  TTG  felt  that 
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adoption  would  be  facilitated  by  fixing  most  parameters,  thereby 
simplifying  implementation.  These  parameters  are  set  or  narrowed 
in  the  proposed  application  profile. 

The  tiling  scheme  developed  provides  a format  that  supports 
operation  on  a subset  of  an  image  without  requiring  other 
portions  of  the  image  to  be  accessed.  For  large-format 
documents,  this  provides  a way  to  interchange  images  between 
systems  of  various  capabilities. 

System  efficiencies  were  a primary  consideration  in  development 
of  the  tiling  scheme  and  interchange  format.  Concerns  associated 
with  processing,  system  cost,  real-time  access,  and  archival 
storage  were  discussed  and  considered.  A tile  format  was 
developed  for  interchange  that  could  also  reasonably  be  used  for 
storage  and  retrieval  without  necessarily  requiring  translation. 

Methodology 

It  was  the  intent  of  the  TTG  to  develop  a proposal  that  used 
existing  and  emerging  standards  as  a basis  wherever  possible. 
This  strategy  assured  that  efforts  were  within  the  mainstream  of 
raster  imaging  standards  and  promoted  interoperability  with  other 
raster  graphics  formats  utilized  in  the  office  document 
standards.  It  was  the  TTG's  intent  to  create  new  mechanisms  or 
objects  only  where  existing  work  could  not  reasonably  accommodate 
the  needs  of  tiling. 

This  work  is  primarily  intended  to  produce  an  interchange  format 
for  simple  exchange  of  large-document  images  between  systems. 
Such  a format  needs  to  have  its  range  of  features  intentionally 
minimized. 

A number  of  potential  capabilities  were  identified  which  could 
have  an  impact  on  the  interchange  format.  These  were  all 
evaluated  and  considered.  Where  appropriate,  some  of  these 
capabilities  were  incorporated,  others  were  reserved  for  future 
consideration,  and  still  others  were  intentionally  excluded. 

Features 

This  section  discusses  features  of  the  proposal.  It  also 
discusses  restrictions  which  were  made  in  the  scope  of  the 
interchange  format  to  ease  user  implementation. 

This  interchange  format  deals  only  with  bi-tonal  (black  and 
white)  data.  Picture  elements  (pels)  are  assumed  to  be  square. 

A tile  is  a rectangular  region  in  a page  in  which  all  regions 
have  the  same  dimensions  (are  regular)  and  no  part  of  any  region 
overlaps  any  other  region.  There  may  not  be  more  than  one  tile 
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imaged  to  a given  tile  location.  Every  tile  that  exists  is 
imaged  to  a single,  unique  tile  location. 

For  the  purposes  of  this  interchange  format,  the  application 
profile  restricts  the  dimensions  for  all  tiles  to  be  square. 
Square  tiles  have  the  desirable  attribute  of  being  easily 
rotated.  Tiles  are  allowed  to  be  absent,  i.e.  to  be  specified  as 
composed  of  all  foreground  or  all  background  pels,  thereby 
removing  the  need  for  including  a content  portion  for  the  tile  in 
question. 

A single  tile  size  is  desirable  to  limit  the  burden  on 
implementors  of  the  interchange  standard.  The  tile  size  is 
specifically  512  by  512  pels.  This  size  was  chosen  as  a 
compromise  between  the  line  buffer  memory  requirements  of  larger 
tiles  and  the  storage  overhead  burden  of  smaller  tiles.  While  it 
was  recognized  that  system  implementations  exist  that  use  256  pel 
or  1024  pel  square  tiles,  all  vendors  present  agreed  that  a 
migration  to  512  pel  square  tiles  was  acceptable  for  interchange. 

Ease  of  implementation  was  a primary  consideration.  Restrictions 
deemed  to  ease  implementation  were:  only  one  page  (one  single 
raster  image)  is  allowed  per  document;  the  page  is  an  integral 
number  of  tiles  in  each  dimension;  and  transparency  is  not  used. 

An  interchange  format  should  include  a minimal  but  sufficient  set 
of  allowable  parameters,  such  as  resolution.  These  parameters 
are  defined  as  attributes  in  the  application  profile. 

Any  given  tile  is  to  be  encoded  as  CCITT  T.6  compressed  data,  as 
bit-map  data,  or  is  specified  as  all  foreground  or  all 
background.  Each  T.6  compressed  tile  ends  in  a EOFB  (end  of 
facsimile  block)  as  specified  in  T.6.  Where  T.6  encoding  is 
used,  the  uncompressed  escape  option  defined  there  is  not 
supported.  This  is  done  because  it  places  an  unreasonable  burden 
on  implementors,  is  not  used  by  any  known  vendors,  and  is  not 
supported  by  existing  or  planned  integrated  circuits.  This 
escape  option  is  rendered  unnecessary  by  the  ability  to  insert 
bit-map  encoded  data  on  a tile-by-tile  basis. 

The  ability  to  intersperse  compressed  and  uncompressed  tiles 
meets  several  crucial  user  requirements.  A system  or  peripheral 
which  must  meet  a given  throughput  requirement  without  failure 
can  selectively  choose  to  leave  uncompressed  those  tiles  which  do 
not  compress  in  a specified  amount  of  time.  Similarly,  when  a 
given  storage  requirement  must  be  met,  this  ability  permits  an 
upper  bound  to  storage  needs  by  using  bit-map  encoding  for  those 
tiles  which  would  have  reverse  compression.  Both  of  these 
requirements  arise  from  the  need  to  predict  the  behavior  of  an 
essentially  statistical  encoding  technique. 
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An  upper  limit  is  set  on  the  number  of  tiles  allowed  in  an  image. 
A limit  of  some  sort  allows  vendors  to  put  a bound  on  system 
memory  requirements. 

Pragma  is  a term  introduced  from  software  terminology  to  describe 
non-required  information  which  can  be  used  to  some  advantage  by  a 
system  implementation,  but  also  can  be  safely  ignored.  An 
example  is  an  attribute  which  specifies  the  starting  location 
(index)  of  a tile  within  the  file.  A system  could  use  this 
information  to  increase  efficiency  or  could  safely  ignore  it  and 
correctly  image  the  file  by  processing  each  tile  in  sequentially. 

Alternatives 

In  an  effort  to  keep  the  interchange  as  simple  as  possible,  a 
number  of  features  were  excluded  or  considered  beyond  the  scope 
of  the  TTG. 

Issues  that  were  considered  but  specifically  excluded  were 
variable  tile  sizes,  rectangular  (non-square)  tiles,  overlapping 
tiles,  tiles  of  variable  transparency,  and  multiple  images  per 
document.  These  and  other  items  could  be  addressed  in  a later, 
separate  application  profile,  but  there  were  strong  feelings  that 
they  do  not  belong  in  a limited,  basic  interchange  format. 

This  proposal  defines  raster  file  format  only  and  not  issues 
related  to  media  or  database  management  such  as  document 
information,  aperture  card  Hollerith  code,  document  and  page 
relationships,  sheets,  revisions,  and  multiple  aperture  card 
frames.  These  issues  are  outside  the  scope  of  the  TTG  and  are 
being  dealt  with  by  other  organizations. 


Summary 

This  document  outlines  the  user  requirements  for  tiled  raster 
graphics  that  were  proposed  by  the  TTG.  The  TTG  proposals  are 
being  implemented  through  the  development  of  an  application 
profile  and  an  addendum  to  the  ISO  8613  Part  7 content 
architecture . 
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1. 


INTRODUCTION 


This  document  application  profile  defines  the  Tiling  Task  Group's 
Agreement  on  the  format  to  be  used  for  the  interchange  of  large 
format  documents.  It  is  based  on  the  Office  Document 
Architecture  (ODA)  and  Interchange  Format,  as  defined  in 
International  Standard  (IS)  8613  and  the  Tiled  Raster  Graphics 
Addendum  to  ISO  8613,  Part  7. 

2.  SCOPE 

2.1.  This  document  application  profile  specifies  an  interchange 
format  suitable  for  interchanging  large  format  documents,  such  as 
engineering  drawings,  that  contain  raster  graphics  implemented 
with  a tiling  scheme. 

2.2.  The  features  of  a document  which  can  be  interchanged  using 
this  document  application  profile  fall  into  the  following 
categories: 

Page  format  features  - these  concern  how  the  layout  of  each 
page  of  a document  will  appear  when  reproduced; 

Raster  graphics  layout  and  imaging  features  - these  concern 
how  the  document  content  will  appear  within  pages  of  the 
reproduced  document;  and 

Raster  graphics  coding  - these  concern  the  raster  graphics 
representations  and  control  functions  that  make  up  the 
document  raster  graphics  content. 

3 . FIELD  OF  APPLICATION 

3.1.  This  document  defines  a document  application  profile  that 
allows  large  format  tiled  raster  documents  to  be  interchanged  in 
a formatted  form  or  formatted  processable  form  in  accordance  with 
ISO  8613. 

3.2.  This  document  application  profile  is  designed  to  be 
independent  of  the  means  used  to  create  or  to  interchange  the 
encoded  documents. 

3.3.  It  is  assumed  that,  when  negotiation  is  performed  by  the 
service  using  this  document  application  profile,  all  non-basic 
features  are  subject  to  negotiation. 
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REFERENCES 


4 . 


The  following  references  are  required  in  order  to  implement  this 
document  application  profile: 

ISO  8613/1  - Information  processing:  Text  and  Office 
Systems;  Office  Document  Architecture  (ODA)  and  Interchange 
Format  Part  1:  Introduction  and  General  Principles 

ISO  8613/2  - Information  processing:  Text  and  Office 
Systems;  Office  Document  Architecture  (ODA)  and  Interchange 
Format  Part  2 : Document  Structures 

ISO  8613/4  - Information  processing:  Text  and  Office 
Systems;  Office  Document  Architecture  (ODA)  and  Interchange 
Format  Part  4:  Document  Profile 

ISO  8613/5  - Information  processing:  Text  and  Office 
Systems;  Office  Document  Architecture  (ODA)  and  Interchange 
Format  Part  5:  Office  Document  Interchange  Format 

ISO  8613/7  - Information  processing:  Text  and  Office 
Systems;  Office  Document  Architecture  (ODA)  and  Interchange 
Format  Part  7 : Raster  Graphics  Content  Architectures 

IS  8613,  Part  7 "Addendum"  (draft):  Tiled  Raster  Graphics 
Addendum  to  ISO  8613,  Part  7 

ISO  8824  - Information  Processing  Systems  - Open  Systems 
Interconnection  - Specification  of  Abstract  Syntax  Notation 
One  (ASN.l) 

ISO  8825  - Information  Processing  Systems  - Open  Systems 
Interconnection  - Specification  of  Basic  Encoding  Rules  for 
Abstract  Syntax  Notation  One  (ASN.l) 

FIPS  PUB  150  - Facsimile  Coding  Schemes  and  Coding  Control 
Functions  for  Group  4 Facsimile  Apparatus  (FED-STD  1065) 
(EIA-538-1988 ) (CCITT  Recommendation  T.6) 


5.  CONFORMANCE 
5.1.  Introduction 

In  order  to  ensure  that  implementations  conform  to  this 
application  profile,  it  is  necessary  to  define  suitable 
conformance  tests  that  implementations  must  pass  before  they  may 
be  classified  as  conformant.  This  section  defines  conformance 
requirements  and  provides  definitions  for  the  interpretation  of 
results  from  conformance  testing. 
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5.2. 


Conformance  Requirements 


Conformance  to  this  document  application  profile  is  defined  in 
terms  of  an  implementation's  ability  to  act  as  an  originator 
and/or  recipient  of  data  streams  conformant  to  the  syntax  and 
semantics  of  ISO  8613  and  the  "Addendum"  as  well  as  meet  all  the 
requirements  listed  below: 

IF  THE  IMPLEMENTATION  IS  AN  ORIGINATOR  : 

1)  generate  data  streams,  for  formatted  document 
architecture  (FDA) 

2)  generate  data  streams  that  include  only  constituents 
specified  in  the  relevant  sections  of  this  document. 

3)  for  each  constituent,  generate  data  streams  that  include 
only  those  attributes  and  combinations  of  attributes 
permitted  by  the  relevant  sections  of  this  document. 

4)  either 

a)  for  each  attribute  of  each  constituent,  generate 
data  streams  that  contain  only  basic  attribute 
values  as  specified  by  the  relevant  sections  of 
this  document. 

or 

b)  for  each  attribute  of  each  constituent,  generate 
data  streams  that  contain  both  basic  and  non-basic 
attribute  values  as  specified  in  the  relevant 
sections  of  this  document. 


IF  THE  IMPLEMENTATION  IS  A RECIPIENT  : 

5)  receive  data  streams,  for  formatted  document  architecture 
(FDA) 

6)  receive  data  streams  that  include  any  of  the  constituents 
specified  in  the  relevant  sections  of  this  document. 

7)  for  each  constituent,  receive  data  streams  that  include 
any  of  the  attributes  or  any  combination  of  attributes 
permitted  by  the  relevant  sections  of  this  document. 
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8 ) either 

a)  for  each  attribute  of  each  constituent,  receive 

data  streams  that  contain  only  basic  attribute 
values  as  specified  by  the  relevant  sections  of 
this  document. 

or 

b)  for  each  attribute  of  each  constituent,  receive 

data  streams  that  contain  either  basic  or  non- 
basic  attribute  values  as  specified  in  the 
relevant  sections  of  this  document. 


5.3.  Conformance  Testing  Definitions 

Any  implementation  that  can  correctly  generate  data  streams  in 
accordance  with  the  conformance  requirements  listed  above  in 
section  5.2,  paragraphs  1),  2),  3)  and  4)a),  is  defined  as  a 

"minimal  conforming  originator." 

Any  implementation  that  can  correctly  receive  data  streams  in 
accordance  with  the  conformance  requirements  listed  above  in 
section  5.2,  paragraphs  5),  6),  7),  and  8)a),  is  defined  as  a 

"minimal  conforming  recipient." 


6.  DEFINITIONS 

The  definitions  in  ISO  8613  and  the  "Addendum"  apply  to  this 
document  application  profile. 

7 . CHARACTERISTICS  SUPPORTED  BY  THIS  DOCUMENT  APPLICATION 

PROFILE 

7.1.  Overview 

A large  format  tiled  raster  document  is  the  result  of  a 
formatting  process  and  therefore  the  purpose  of  this  document 
application  profile  is  to  allow  transfer  of  the  complete  layout 
of  the  interchange  document. 

Only  one  category  of  content  is  allowed  within  the  same  page, 
namely,  a tiled  raster  graphics  content. 

This  section  describes  the  layout  features  that  can  be 
represented  in  documents  conforming  to  this  document  application 
profile.  The  features  are  described  in  terms  that  are  typical  of 
the  user-perceived  capabilities  and  semantics  found  in  current 
document  processors. 
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7.2.  Document  profile 


Every  document  interchanged  in  accordance  with  this  document 
application  profile  must  include  a document  profile  containing 
information  which  relates  to  the  document  as  a whole.  The 
document  profile  used  in  this  document  application  profile  must 
identify  the  contents  as  tiled  raster  graphics  data.  Every  non- 
basic  attribute  value  used  in  a document  must  be  indicated  in  the 
document  profile. 

7.3.  Logical  Characteristics 

A logical  structure  of  the  document  conforming  to  this 
application  profile  consists  of  a two  level  hierarchy  of  a 
logical  document  root  and  tiled  raster  graphics  content. 

7.4.  Layout  Characteristics 

7.4.1.  Document  layout  structure 

A document  layout  structure  contains  a page  of  tiled  raster 
graphics  contents. 

7.4.2.  Document 

A document  consists  of  only  a single  page. 

7.4.3.  Page  layout 

This  document  application  profile  supports  various  page 
dimensions  including  the  nominal  page  sizes  of  the  North  American 
A-K  and  ISO  A4-A0  formats.  The  standard  default  is  the  nominal 
page  size  of  the  North  American  A format  since  this  is  the  most 
common  size. 

A page  layout  contains  only  tiled  raster  graphics  contents 
consisting  of  as  many  tiles  as  is  necessary  to  represent  the 
image  in  digital  form. 

7.5.  Content  Characteristics 

7.5.1.  The  content  characteristics  of  this  document  application 
profile  will  contain  only  large  format  tiled  raster  data.  Only 
the  CCITT  Recommendation  T.6  Group  4 compression  algorithm  will 
be  used  except  where  it  is  more  efficient  to  retain  a tile  image 
in  bit-map  format  or  to  have  no  encoded  tile  content  (null) . 

7.5.2.  The  contents  of  a page  consisting  of  tiled  raster 
graphics  is  defined  by  the  type  of  coding  and  the  dimensions  of 
the  array  of  picture  elements  (pels) . The  attributes  to  define 
the  contents  are  specified  in  ISO  8613-7  and  the  "Addendum." 
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7.5.3.  The  presentation  of  the  tiled  raster  graphics  content 
block  is  controlled  by  the  presentation  attributes  specified  in 
ISO  8613-7  and  the  "Addendum". 

8 . TECHNICAL  SPECIFICATION 

8.1.  Summary  of  Technical  Specification 

8.1.1.  Overview 

This  section  contains  the  technical  specification  of  the  document 
application  profile  for  large  format  tiled  raster  documents. 

This  document  application  profile  allows  documents  to  be 
represented  in  the  following  forms: 

- formatted  form,  which  allows  a recipient  to  reproduce  the 
document  as  intended  by  the  originator;  or 

formatted  processable  form,  which  facilitates  the 
reproduction  of  a document  as  intended  by  the  originator  or 
facilitates  the  revision  of  a document. 

8.1.2.  Specification  of  Constituents 

This  section  specifies  the  required  constituents  used  for  the 
representation  of  documents  that  conform  to  this  application 
profile.  Also,  it  specifies  the  content  architectures  that  may 
be  present  in  these  documents.  There  are  no  optional 

constituents . 

Constituents  specified  as  "required"  must  occur  in  any  document 
that  conforms  with  this  application  profile.  Constituents  listed 
as  "optional"  may  or  may  not  be  present  in  the  document  depending 
upon  the  requirements  of  a particular  application. 

8. 1.2.1.  Constituents  for  formatted  form  documents 

The  required  constituents  include; 

- a document  profile,  and 

- layout  object  descriptions  representing  a specific  layout 
structure . 

There  are  no  optional  constituents. 
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8 . 1 . 2 . 2 . 


Constituents  for  formatted  processable  form  documents 


The  required  constituents  include: 
a document  profile, 

- logical  object  descriptions  representing  a specific 
logical  structure,  and 

layout  object  descriptions  representing  a specific  layout 
structure. 

The  optional  constituents  include: 
layout  styles,  and 
presentation  styles. 

8.1.3.  Notation  and  Constraints 

This  section  presents  the  notation  used  to  define  the  permissible 
structures  and  attribute  values  for  this  document  application 
profile. 

Attributes  in  the  tables  specifying  values  for  the  tiled  raster 
graphics  format  specify  BASIC,  NON-BASIC,  and  DEFAULT  values. 
For  example, 

Line-Progression  BASIC  {90,270  } 

NON-BASIC  (NONE  } 

DEFAULT  (270  } 

specifies  that  the  Line-Progression  attribute  may  be  one  of  the 
two  possible  directions  of  either  90  or  270;  that  no  values  other 
than  basic  values  are  allowed;  and  that  the  default  is  270. 

There  is  only  one  non-basic  value,  12  SMU,  allowed  for  attribute 
the  Pel-Transmission-Density  in  the  layout  object  descriptions. 
The  respective  default  values,  when  different  from  ISO  8613  and 
the  "Addendum,"  are  specified  in  the  document  profile  attribute 
"document  application  profile  defaults."  For  example, 

dimensions  ( #horizontal ( #f ixed{ 10200 } ) 

( #vertical ( #f ixed{ 13200 }} } 

specifies  for  the  document  profile  attribute  dimensions  that  the 
default  values  for  the  horizontal  and  vertical  are  equal  to  the 
common  nominal  page  size  of  North  American  Letter. 
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The  keywords  used  in  this  document  are  defined  as  follows: 

AS_8613  - Used  to  denote  that  any  value  may  be  specified 
that  is  both  consistent  with  the  rules  of  this  document 
application  profile  and  is  permitted  in  ISO  8613; 
however,  for  the  convenience  of  using  this  document,  the 
attribute  values  may  be  listed  instead  of  using  AS_8613 

AS_8613Adden  - Used  to  denote  that  any  value  may  be 
specified  that  is  both  consistent  with  the  rules  of  this 
document  application  profile  and  is  permitted  in  the  ISO 
8613-7  "Addendum" 

NONE  - Used  to  indicate  that  there  are  no  valid  values  for 
this  attribute  or  parameter 

/*  */  - These  characters  used  in  this  combination  are  used 

to  enclose  comments  about  the  constituent  and  attribute 
specifications . 

OBJECT_CLASS_ID_OF 

Used  to  specify  any  object  call  identifier  from  the  set  of 
instances  of  a particular  constituent  constraint. 

STYLE_OF 

Used  to  specify  any  style  identifier  from  the  set  of  instances  of 
a particular  style  constraint. 

8.2.  Logical  Structure 

This  section  defines  all  of  the  logical  structure  constituent 
constraints.  Each  constituent  constraint  has  three  parts:  a list 
of  required  (mandatory)  attributes;  and  a list  of  permitted 
(optional)  attributes;  and  an  optional  list  of  relationships  with 
other  constituent  constraints. 

The  number  of  hierarchical  levels  allowed  is  2,  namely: 
document  logical  root;  and 
basic  logical  component. 

These  levels  are  all  mandatory.  A single  content  portion  is 
associated  with  the  basic  logical  component. 
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8.2.1.  Logical  Document 

REQUIRED 

Object-Type 

Object-Class-Identif ier 

Object-Identifier 

Object-Class 

PERMITTED 

User-Readable-Comments 

User-Visible-Name 

Default-Value-Lists 

Protection 


{ document-logical-root } 
{AS_8613 } 

{AS_8613 } 

{OBJECT_CLASS_ID_OF(Logdoc) } 


{AS_8613 } 
{AS_8613 ) 
{AS_8613 } 
{AS_8613) 


8.2.2.  Basic  Logical  Component.  Raster 


REQUIRED 

Object-Type 

Object-Class-Identif ier 

Object-Identifier 

Object-Class 

PERMITTED 

Content-Portions 

Content-Architecture-Class 

Presentation-Style 

User-Readable-Comments 

User-Visible-Name 

Protection 

Layout-Style 

Application-Comments 


{basic-logical -object) 
(AS_8613 } 

{AS_8613) 

{OBJECT_CLASS_ID_OF (Raster) } 


{AS_8613 } 

(28272)  /*  rfp  */ 

(STYLE_0F(P-Style3) ) 
(AS_8613 ) 

(AS_8613 ) 

(AS_8613 ) 

{STYLE_0F(L-Style6) ) 

{ Tile-Content-Offset) 


8.2.3.  Presentation  Styles  for  Raster.  P-Stvle3 


REQUIRED 


Presentation-Style-Identif ier  { AS_8613 ) 
Content-Architecture-Class  (28272)  /*  rfp  */ 

PERMITTED 


Colour 

Raster-Graphic-Presentation- 

Attributes 

User-Readable-Comments 

User-Visible-Name 


(AS_8613 ) 

/*  see  section  on  raster 
graphics  content  */ 
(AS_8613 ) 

(AS_8613 ) 
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8.2.4.  Layout  Styles  for  Raster.  L-Stvle6 


REQUIRED 


Layout-Style-Identif ier 


{AS_8613 } 


PERMITTED 


Indiyisibility 
Layout-Category 
Layout-Ob j ect-Class 
New-Layout-Ob j ect 
Offset 

Same-Layout-Ob j ect 
Separation 

User-Readable-Comments 

User-Visible-Name 


{AS_8613 ) 
{AS_8613 } 
{AS_8613 } 
{AS_8613 } 
{AS_8613} 
{AS_8613 } 
(AS_8613 } 
{AS_8613 } 
{AS_86I3 ) 


8.3.  Layout  Structure 

This  'section  defines  all  of  the  layout  structure  constituent 
constraints.  Each  constituent  constraint  has  three  parts:  a list 
of  required  (mandatory)  attributes;  and  a list  of  permitted 
(optional)  attributes;  and  an  optional  list  of  relationships  with 
other  constituent  constraints. 

8.3.1.  Generic  layout  structure 
Not  Applicable 

8.3.2.  Specific  layout  structure 

The  number  of  hierarchical  leyels  allowed  is  2,  namely: 

- document  layout  root;  and 

- page. 

These  levels  are  all  mandatory.  A single  content  portion  is 
associated  with  each  page, 

8 . 3 . 2 . 1 . Document  layout 

REQUIRED 

Ob j ect-Type  { document-layout-root } 

Object-Identifier  {AS_8613} 


IV-10 


8 . 3 . 2 . 2 . Page 


REQUIRED 


Object-Type 

Object-Identifier 


(page) 
{AS_8613 } 


PERMITTED 


Appl ication-Comments  {Tile-Content-Offset } 


/*  This  is  a structured  attribute  for 
tile  indexing,  see  paragraph  8.4.4  */ 


Dimensions 


{ NA-A , NA-L, NA-B , NA-C , NA-D , NA-E , NA-F , 

NA-G , NA-H , NA-J , NA-K, ISO-AO , ISO-Al , 
ISO-A2,ISO-A3,ISO-A4}  /*  See  table  1, 


para  8. 3. 2. 4 */ 


Content-Portions 


{AS_8613Adden) 

/*  The  contents  must  be  Tiled  Raster 
Format  0 (trf-0) . */ 


8. 3. 2. 3.  Dimensions  for  Page  Sizes 

The  horizontal  and  vertical  dimensions  will  be  the  nominal  page 
sizes  measured  in  Basic  Measurement  Units  (BMU)  for  the  various 
page  sizes  ISO  A0-A4  and  North  American  (NA)  A-K.  The  value  of 
the  BMU  is  equal  to  1/1200  of  25.4mm  (see  ISO  8613/2,  paragraph 
3.3.4).  The  allowable  BASIC  BMU  values  are  identified  in  the 
following  table. 
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NOMINAL 

BMU 

PAGE  SIZE 

PAGE  SIZE 

WID  X LEN 

HORIZONTAL 

VERTICAL 

Metric 

(mm) 

IS0-A4 

210X297 

9920 

14030 

IS0-A3 

297X420 

14030 

19840 

IS0-A2 

420X594 

19840 

28060 

ISO-Al 

594X840 

28060 

39680 

ISO-AO 

840X1188 

39680 

56120 

North 

American 

( inches) 

NA-A 

8.5X11 

10200 

13200 

NA-L 

8.5X14 

10200 

16800 

NA-B 

11X17 

13200 

20400 

NA-C 

17X22 

20400 

26400 

NA-D 

22X34 

26400 

40800 

NA-E 

34X44 

40800 

52800 

NA-F 

28X40 

33600 

48000 

NA-G 

11X90 

13200 

108000 

NA-H 

28X143 

33600 

171600 

NA-J 

34X176 

40800 

211200 

NA-K 

40X143 

48000 

171600 

TABLE  1.  Dimensions  for  Various  Page  Sizes 


8.4.  Tiled  Raster  Graphics  Content  Architecture 

The  Tiled  Raster  Graphics  Content  Architecture  permits  the 
inclusion  in  documents  of  content  portions  containing  tiled 
raster  graphics.  Tiled  raster  graphics  represent  a two- 
dimensional  pictorial  image  in  the  form  of  a rectangular  two- 
dimensional  array  of  picture  elements  (pels)  divided  into  non- 
overlapping regions  called  tiles.  The  content  architecture  is  as 
specified  in  part  7 of  ISO  8613  and  its  "Addendum." 

The  Tiled  Raster  Graphics  Content  Architecture  defines  a 
formatted  or  formatted  processable  content  architecture.  This 
content  architecture  class  supports  Presentation  Attributes  and 
Content  Portion  Attributes.  Each  attribute  comprising  this 
content  architecture  is  specified  in  subsequent  sections  in  a 
form  that  has  been  defined  previously.  For  each  attribute, 
permissible  values  are  differentiated  as  BASIC,  NON-BASIC  and 
DEFAULT. 
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8.4.1. 


Presentation  Attributes 


These  attributes  specify  constraints  and  initial  conditions 
relating  to  the  layout  and  imaging  of  a tiled  raster  graphics 
content  portion. 


Pel-Path  BASIC  {0  90  180  270) 

NON-BASIC  (NONE) 

DEFAULT  { 0 } 

/*  Direction  of  the  progression  of 
successive  pels  along  a line,  relative 
to  the  horizontal  axis  of  the  basic 
layout  object.  */ 


Line-Progression 


Pel -Transmission-Density 


BASIC 
NON -BASIC 
DEFAULT 


{90  270) 

(NONE) 

(270) 


/*  Direction 

of 

the 

progression 

of 

successive  lines. 

relative 

to  the 

pel 

path.  */ 

BASIC  (1, 

/*  1200 

*/ 

2, 

/* 

600 

*/ 

3, 

/* 

400 

*/ 

4, 

/* 

300 

*/ 

5, 

/* 

240 

*/ 

6) 

/* 

200 

*/ 

NON-BASIC  (12) 

/* 

100 

*/ 

DEFAULT  ( 6 ) 

/* 

200 

*/ 

/*  Attribute 

values 

are 

SMU  values 

representing 

the 

Pels  per  25.4 

mm 

density  */ 


Initial-Offset  BASIC  (Horizontal  offset  = 

any  integer, 

Vertical  offset  = 
any  integer) 
NON-BASIC  (NONE) 

DEFAULT  (see  table  2, 

8613/7) 
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Clipping 


Pel-Spacing 


{ 

{ First-Pair-X-Coordinate 
BASIC  {AS_8613} 

NON-BASIC  {NONE} 

DEFAULT  (AS_8613)) 

( First-Pair-Y-Coordinate 
BASIC  (AS_8613} 

NON- BASIC  (NONE) 

DEFAULT  (AS_8613}) 

{ Second-Pair-X-Coordinate 
BASIC  (AS_8613} 

NON-BASIC  (NONE) 

DEFAULT  { AS_8  613}) 

( Second-Pair-Y-Coordinate 
BASIC  {AS_8613} 

NON-BASIC  (NONE) 

DEFAULT  (AS_8613}} 

} 

/*  Used  to  identify  the  useful  portion  o 
image,  say,  within  an  over-scanned  image 


{ 

( Length 


{ Pel-Spaces 


} 


BASIC 

NON-BASIC 

DEFAULT 

BASIC 

NON-BASIC 

DEFAULT 


(AS_8613 } 
{ NONE } 
{4}} 

(AS_8613 } 

(NONE) 

{!}} 


Spacing-Ratio 


{ 

( Line-Spacing-Value 
BASIC 
NON-BASIC 
DEFAULT 

( Pel-Spacing-Value 

BASIC 

NON-BASIC 

DEFAULT 

) 


(AS_8613} 
{ NONE } 
{1}} 

(AS_8613 } 

(NONE) 

{!}} 


IV-14 


* i-h 


Image-Dimensions 


BASIC  {CHOICE-OF 

{Width-Controlled  (SEQUENCE-OF 

(Minimum-Width  BASIC  (AS_8613} 

NON-BASIC  (NONE) 

DEFAULT  {NO-DEFAULT}} 
{ Preferred-Width 

BASIC  {AS_8613} 

NON-BASIC  {NONE} 

DEFAULT  {NO-DEFAULT}} 

}) 

{Height-Controlled  {SEQUENCE-OF 
{Minimum-Height 

BASIC  {AS_8613} 

NON-BASIC  {NONE} 

DEFAULT  {NO-DEFAULT}} 
{ Preferred-Height 

BASIC  {AS_8613} 

NON-BASIC  {NONE} 

DEFAULT  {NO-DEFAULT}} 

}} 

{Area-Controlled  {SEQUENCE-OF 


{Minimum-Width  BASIC 

{AS  8613} 

NON-BASIC 

{ NONE } 

DEFAULT 

{NO-DEFAULT} } 

{ Preferred-Width 

BASIC 

{AS  8613} 

NON -BASIC 

{NONE} 

DEFAULT 

{NO-DEFAULT} } 

{Minimum-Height 

BASIC 

{AS  8613} 

NON-BASIC 

{NONE} 

DEFAULT 

{ NO -DE FAULT } } 

{ Preferred-Height 

BASIC 

{AS  8613} 

NON-BASIC 

{ NONE } 

DEFAULT 

{NO-DEFAULT} } 

{Aspect-Ratio-Flag 

BASIC 

{variable! fixed} 

NON -BASIC 

{NONE} 

DEFAULT 

}} 

{Automatic  BASIC 

{NO-DEFAULT} } 

{NO -PARAMETERS} 

NON-BASIC 

{N/A} 

DEFAULT 

} 

NON-BASIC 

{N/A}} 

{ NONE } 

DEFAULT 

{AUTOMATIC} 
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8.4.2.  Content  Portions  Attributes 


Type-of-Coding  BASIC  {28374} 

/*' tiled  T6  encoding'*/ 

{ 2 8 3 7 7 } 

/★'tiled  bitmap  encoding'*/ 

{ 2 8 3 7 8 } 

/★'tiled  T6  and  bitmap 
encoding ' */ 

/*  ASN.l  object  identifiers  to 
process  tiled  raster  graphics 
to  be  assigned  */ 

NON-BASIC  {NONE} 

DEFAULT  {28378} 

/★'tiled  T6  and  bitmap 
encoding ' ★/ 

Compression  BASIC  {compressed} 

NON-BASIC  {NONE} 

DEFAULT  {compressed} 

/★  Uncompressed  escape  option  (extension 
code)  is  not  supported  ★/ 


Number-Of-Pels-Per-Line  BASIC  {any  positive 

integer  less  than 

211,200} 

/★see  Notes  1 & 2 ★/ 
NON-BASIC  {NONE} 

DEFAULT  {NONE} 


Number-Of-Lines  BASIC  {any  positive 

integer  less  than 

211,200} 

/★see  Notes  1 & 2 ★/ 
NON-BASIC  {NONE} 

DEFAULT  {NONE} 


Number-Of-Pels-Per-Tile-Line 

BASIC  {512} 

NON-BASIC  {NONE} 
DEFAULT  {512} 
/★  see  Note  2 ★/ 


Number-Of-Lines-Per-Tile  BASIC  {512} 

NON-BASIC  {NONE} 

DEFAULT  {512} 

/★  see  Note  2 ★/ 

Note  1:  These  values  are  restricted  to  be  positive 

integers  which  correspond  to  an  integral  number  of 
tiles  in  the  respective  dimension.  Their  values 
must  be  no  larger  than  211,200  which  represents 
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Note  2 : 


Tile-Type 


Tiling-Offset 


the  maximum  dimensions  of  a J size  drawing  at  1200 
density. 

The  four  attributes  Number-Of -Pel  s-Per-Line , 
Number-Of-Lines , Number-Of-Pels-Per-Tile-Line , & 
Number-Of-Lines-Per-Tile  can  be  used  to  calculate 
the  number  of  tiles  in  the  image  which  should  not 
exceed  4096.  This  provides  for  the  representation 
of  a K size  drawing  at  a Pel-Transmission-Density 
of  3 SMU  (400  dots/inch) . The  formula  for 
computing  the  total  number  of  tiles  in  the  image 
is:  (Number-Of-Pels-Per-Line  / Number-Of-Pels-Per- 
Tile-Line)  * (Number-Of-Lines  / Number-Of-Lines- 
Per-Tile) . 


BASIC  {null  background, 

null  foreground, 
bit  map  encoded, 

T.6  encoded} 

NON-BASIC  (NONE) 

DEFAULT  (NONE) 

/*  This  attribute  is  used  to  specify  a 
sequence  of  integers,  one  per  tile. 
Each  integer  specifies  the  type  of 
coding  of  the  corresponding  tile  in  the 
content  portion.  Null  indicates  an 
absence  of  data  on  either  a background 
color  (null  background)  or  a foreground 
color  (null  foreground) . */ 

(X  ( BASIC  (AS_8613Adden} 

NON-BASIC  (NONE) 

DEFAULT  ( 0 ) ) , 

(Y  ( BASIC  (AS_8613Adden} 

NON-BASIC  (NONE) 

DEFAULT  ( 0 ) ) ) 

/*  This  is  a coordinate  pair  specifying 
the  location  of  the  pel  array  within  the 
tile  space  by  defining  the  offset  of  the 
first  pel  of  the  pel  array  from  the 
first  pel  position  of  the  first  tile.  */ 
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8.4.3.  Application  Specific  Attributes 


Tile-Content-Offset  BASIC  {Sequence  of  positive 

integers } 

NON- BASIC  (NONE) 

DEFAULT  (NONE) 

/*  This  attribute  consists  of  a sequence 
of  positive  integers,  one  for  each  tile. 
Each  integer  value  will  be  the  distance 
in  bytes  from  the  beginning  of  the  index 
to  the  respective  tile.  The  integers 
will  be  sequenced  in  the  same  order  as 
the  tiles.  The  tiles  will  be  sequenced 
primarily  in  the  line  progression 
direction  and  secondarily  in  the  pel 
path  direction  as  defined  by  the 
presentation  attributes.  */ 

8.4.4.  Document  profile  attributes 

8.4.4. 1.  Presence  of  document  constituents 

REQUIRED 

Specific  Layout  Structure  (AS_8613} 

8. 4. 4. 2.  Document  characteristics 


REQUIRED 

Document-Application-Profile 


Document-Architecture-Class 

Content-Architecture-Class 


Interchange-Format-Class 

ODA-Version 

Document-Reference 

Document-Application-Profile 


{ ) 

/*  ASN.l  object  identifier 
to  be  supplied  */ 

{ formatted) 

{ ) 

/*  ASN.l  object  identifier 
to  be  supplied  */ 

(A) 

(ISO  8613,  1988-XX-XX) 

(AS_8613 ) 

Defaults 

(Dimensions  (#horizontal  (10200) 
#vertical  (13200)) 
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NON-BASIC  Document  Characteristics 


PERMITTED 

Pel-Transmission-Density  {12}  /*  100  SMU  */ 

Dimensions  { NA-A , NA-L, NA-B, NA-C , NA-D , 

NA-E , NA-F , NA-G , NA-H , NA- J , 

NA-K, ISO-AO, ISO-Al, ISO-A2 , 
ISO-A3,ISO-A4)  /*  See  table  1, 
para  8. 3. 2. 4 */ 

9 . DOCUMENT  INTERCHANGE  FORMAT 

The  aspects  of  this  document  application  profile  are 
concerned  with  the  interchange  format  of  large  raster 
graphics  documents.  These  aspects  include  the  data  stream, 
the  interchange  data  units,  and  ASN.l  encodings. 

9.1.  Data  Stream 


The  data  stream  is  in  accordance  with  the  Office  Document 
Interchange  Format  Class  A,  as  defined  in  ISO  8613-5. 

The  encoding  is  in  accordance  with  the  Basic  Encoding  Rules 
for  Abstract  Syntax  Notation  One  (ASN.l),  as  defined  in  ISO 
8825. 


9.2.  ASN.l  Generation  and  Parsing 

This  clause  covers  two  distinct  aspects  of  ASN.l  generation 
and  parsing.  The  first  aspect  covers  ASN.l  practices  that  are 
mandatory  for  an  implementation  to  be  conforming  to  this 
document.  The  second  aspect  covers  ASN.l  practices  that  are 
recommended  by  this  document.  These  recommended  practices  are 
not  mandatory  for  conformance,  but  are  recommended  solely  in 
the  spirit  of  improving  interoperability  among  different 
implementations . 


9.2.1.  ASN.l  Generation  Requirements 

There  are  no  additional  requirements,  beyond  ISO  8824  and  ISO 
8825,  imposed  on  the  ASN.l  generation. 

9.2.2.  ASN.l  Parsing  Requirements 

There  are  no  additional  requirements,  beyond  ISO  8824  and  ISO 
8825,  imposed  on  the  ASN.l  parsing. 
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9.2.3. 


ASN.l  Generation  Recommendations 


The  focus  of  the  ASN.l  generation  recommendations  is  to 
generate  ASN.l  encodings  that  will  allow  parsing  by  the  most 
rudimentary  of  implementations.  These  recommendations  are 
described  in  the  following  sub-clauses. 


Segmenting  Strings 

ISO  8825  allows  Bit  Strings,  Octet  Strings,  and  Character  Set 
Strings  to  be  encoded  in  the  Primitive  form  or  in  the 
Constructed  form.  The  choice  of  which  form  to  use  is  an 
option  of  the  encoder.  Using  the  constructed  form  allows  a 
string  to  be  segmented  into  a sequence  of  strings.  This 
sequence  of  strings  is  then  contained  in  the  constructed  form 
of  the  string.  The  constructed  form  is  allowed  the  use  of  the 
indefinite  form  on  content  length. 

This  document  _.,_x.ecommends  that  implementations  limit  the 
encoding  to  one  level  of  the  constructed  form  for  Bit 
Strings,  Octet  Strings,  and  Character  Set  Strings. 

For  example,  if  of  type  OCTET  STRING,  the  value 
' 432E436F6D6273 ' H can  be  encoded  in  the  primitive  form  as: 

Octet 

String  Length  Contents 
04i6  07i5  432E436F6D6273i6 

The  same  value  may  be  encoded  in  the  constructed  from  as: 


Octet 

String  Length  Contents 
24i6  80i6 

Octet 

String  Length  Contents 

04i6  02^5  432Ei5 

04i6  05i6  436F6D6273i6 

EOC  Length 

00i6  OO^g 
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The  same  value  encoded  using  two  levels  of  constructed  form 
is  not  recommended  by  this  Implementors  Agreement.  An 
example  of  an  encoding  containing  two  levels  of  construction 
is : 

Octet 

String  Length  Contents 
24i6  80i6 

Octet 

String  Length  Contents 

24ig  04^5 

Octet 

String  Length 


Contents 

432Ei6 

04i6 

02i6 

436F6D6273ig 

04i6 

05i6 

EOC 

Length 

OO16 

OO16 

Length  Expression 

ISO  8825  allows  the  content  length  of  an  encoding  that  could 
be  expressed  using  the  short  form  to  also  be  expressed  using 
the  long  form.  For  example,  a length  of  one  could  be 
expressed  in  the  short  form  as  OOOOOOOI2  or  in  the  long  form 
as  IOOOOOOI2  OOOOOOOI2.  CCITT  Recommendations  X.208  and 
X.209  are  identical  to  ISO  8824  plus  Addendum  1 and  ISO  8825 
plus  Addendum  1 . 

This  document  recommends  that  implementations  generate 
content  lengths  only  in  their  most  economical  form. 


Ordering  of  Set  Members 

ISO  8824  defines  sets  to  be  unordered  lists  of  values.  It  is 
the  generator's  option  to  select  an  order  for  the  values  of 
the  set.  Since  this  ordering  is  unpredictable  from  one 
implementation  to  the  next,  it  is  recommended  that  generators 
order  the  values  in  a set  according  to  the  order  in  which  the 
members  appear  in  the  definition  of  the  set.  The  intent  of 
this  recommendation  is  to  reduce  the  possible 
interoperability  problems  associated  with  the  unpredictable 
ordering  of  members  in  a set. 
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9.2.4.  ASN.l  Parsing  Recommendations 


The  overall  intent  of  these  parsing  recommendations  is  to 
allow  a high  tolerance  in  the  representation  of  the  ASN.l 
syntax  without  jeopardizing  the  semantics  of  the  information 
being  conveyed.  Each  of  these  tolerances  is  described  in  a 
following  sub-clause. 

Segmented  Strings 

The  ASN.l  generation  restriction  on  segmenting  strings  is  a 
recommendation  of  this  Implementors  Agreement  and  is  not  a 
requirement  of  ISO  8825.  Therefore,  it  is  recommended  that 
implementations  accept  string  encodings  which  have  been 
segmented  into  more  than  one  level  of  the  constructed  form. 
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ANNEX  A 


Format  of  the  values  of  the  attributes  "object  identifier” 

and  "subordinates'*. 


The  object  identifiers  of  the  specific  layout  object 
descriptions  are  composed  of  sequences  of  numbers,  each  of 
these  numbers  representing  a particular  level  of  the  specific 
layout  structure. 

The  number  assigned  to  the  specific  document  layout  root 
object  description  is  "1."  The  subordinate  pages  have  a 
second  number  which  uniquely  identifies  a particular  page. 
The  delimiter  between  "1"  and  this  second  number  is  the 
"space"  character. 

Example: 

"1  27"  corresponding  coding:  '31  20  32  37 'H 

The  subordinate  block  identifiers  are  composed  of  the 
identifier  of  the  page  to  which  they  belong  extended  with  an 
additional  number  which  uniquely  identifies  a particular 
block.  The  delimiter  between  the  prefix  derived  from  the 
page  identifier  and  this  additional  number  is  the  "space" 
character. 


Example: 

"1  27  5"  corresponding  coding:  '31  20  32  37  20  35 'H 

Content  portion  identifiers  are  composed  of  the  identifier  of 
the  object  to  which  the  content  portion  belongs  and  an 
additional  number  which  uniquely  identifies  a particular 
content  portion. 

Examples : 

block  description  "1  27  5"  coding:  ' 312032372035 ' H 
content  portion  "1  27  5 6"  coding: 

' 3120323720352036 'H 
associated  with  the  block 

The  value  of  the  attribute  "content  portion"  consists  of  a 
sequence  of  numbers,  each  of  which  indicates  a content 
portion  of  that  object.  Each  of  these  numbers  is  equal  to 
the  last  number  in  the  content  portion  identifier. 
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INFORMATION  PROCESSING 


TEXT  AND  OFFICE  SYSTEMS 


OFFICE  DOCUMENT  ARCHITECTURE  (ODA)  AND  INTERCHANGE  FORMAT 
PART  7:  RASTER  GRAPHICS  CONTENT  ARCHITECTURES 
TILED  RASTER  GRAPHICS  ADDENDUM 


Add  the  following  definition  to  clause  3 (Definitions)  of  ISO 
8613-7  and/or  to  the  definitions  of  ISO  8613-1. 

3.1  tile 

One  element  of  a two  dimensional  array  of  non-overlapping 
rectangular  regions  of  a pel  array. 

Add  the  following  paragraphs  to  clause  4.5  (Coding  of  content 
information)  of  ISO  8613-7. 

The  pel  array  may  be  subdivided  into  a two  dimensional  array 
of  nonoverlapping  rectangular  regions  called  tiles.  The 
content  information  of  each  tile  is  coded  independently  of 
the  content  information  of  the  other  tiles  of  the  same  pel 
array. 

Tiling  facilitates  convenient  access  to,  and/or  processing  of 
portions  of  the  pel  array  independent  of  access  to,  and/or 
processing  of  other  portions.  It  also  provides  data 
compression  for  tiles  of  uniform  pel  values. 

NOTE  - Tiling  provides  an  alternative  method  for  coding 
of  raster  graphics  content  and  therefore  does  not  affect 
the  positioning  of  the  clipped  pel  array. 

Add  the  following  clause  after  clause  5.4.3  (Positioning 
rules  for  formatted  processable  content)  of  ISO  8613-7. 

5.5  Positioning  of  tiled  pels 

Where  the  pel  array  is  subdivided  by  tiles,  the  basic 
concepts,  pel  image  model  and  positioning  of  pels  in  a basic 
layout  object  presented  above  continue  to  apply.  Furthermore 
the  attributes  for  pel  array  clipping  continue  to  apply  to 
the  pel  array. 

The  arbitrary  location  of  the  pel  array  in  the  tile  set  may 
result  in  some  tiles  being  only  partially  filled  with 
content.  The  location  of  pel  array  content  relative  to  the 
tile  content  is  specified  by  the  "tiling  offset"  attribute. 
Figure  4 illustrates  the  location  of  the  pel  array  in  the 
tile  set. 
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Number  of  pels  per  line 


Figure  4 - Example  of  positioning  of  tiled  pels  within  a 

basic  layout  object 

A tile  is  defined  by  referencing  either  the  pel  positioning 
coordinate  system  or  the  pel  identification  coordinate  system 
associated  with  the  following  values: 


Abbreviation 

Descriotion 

npl 

number  of  pels  per 

line 

nl 

number  of  lines 

nptl 

number  of  pels  per 

tile  line 

nit 

number  of  lines  per  tile 

Is 

line  spacing 

ps 

pel  spacing 

ntppd 

number  of  tiles  in 

the  pel  path  direction 

ntlpd 

number  of  tiles  in 
direction 

the  line  progression 

toppd 

tile  offset  in  the 

pel  path  direction 

tolpd 

tile  offset  in  the 

line  progression  direction 
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In  the  pel  positioning  coordinate  system  a tile  is  that  part 
of  the  pel  array  consisting  of  all  pels  whose  reference 
points  have  coordinates  (x,y)  such  that: 

xp+ (i*nptl*ps)  <=  X < xp+( (i+1) *nptl*ps) 


and 


yp+ ( j*nlt*ls)  <=  y < yp+( (j+i) *nlt*ls) 


where 

i and  j are  non-negative  integers, 

xp  and  yp  are  the  coordinates  of  the  initial  point 

all  non-integer  values  arising  in  coordinate 
computations  are  rounded  up  to  an  integer  number  of 
SMUs. 

In  the  pel  identification  coordinate  system  a part  of  the  pel 
array  consisting  of  all  pels  with  coordinates  (x,y)  such 
that: 


i*nptl  <=  X <=  ( (i-f  1)  *nptl) -1 


and 


j*nlt  <=  y <=  ( ( j+1) *nlt) -1 
for  some  non-negative  integers  i and  j . 

These  equations  define  a set  of  tiles  as  two  dimensional 
array  of  non-overlapping  rectangles  of  equal  size.  The  tile 
set  is  superimposed  on  the  pel  array  such  that  each  tile 
overlays  a portion  of  the  pel  array.  Tiles  at  the  periphery 
of  the  pel  array  are  not  required  to  completely  overlay  the 
pel  array.  The  vertical  and  horizontal  extent  of  the  tile 
set  may  overlap  the  pel  array  consistent  with  the  following 
equations : 

ntppd  = INT ( (npl+toppd)/nptl) +1 


and 


ntlpd  = INT ( (nl+tolpd) /nit) +1 


where 


INT  signifies  numerical  truncation  yielding  the 
unrounded  integer  portion  of  a real  number. 
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Add  the  following  to  the  end  of  the  permissible  value  list  in 
clause  7.1.1  (Type  of  coding)  of  ISO  8613-7. 


{ 

2 

8 

3 

7 

4 

} 

for 

{ 

2 

8 

3 

7 

5 

} 

for 

{ 

2 

8 

3 

7 

6 

} 

for 

{ 

2 

8 

3 

7 

7 

} 

for 

{ 

2 

8 

3 

7 

8 

} 

for 

'tiled  T6  encoding', 
'tiled  T4  one  dimensional 
encoding ' , 

'tiled  T4  two  dimensional 
encoding ' , 

'tiled  bitmap  encoding', 
'tiled  T4 , T6  or  bitmap 
encoding ' 


Add  the  following  to  the  end  of  the  list  of  dashed  items  in 
the  definition  area  of  clause  7.1.1  (Type  of  coding)  of  ISO 
8613-7. 


'tiled  T6  encoding',  according  to  the  tiling  scheme 
defined  herein  and  the  two  dimensional  encoding  scheme 
defined  in  CCITT  Recommendation  T.6; 

'tiled  T4  one  dimensional  encoding',  according  to  the 
tiling  scheme  defined  herein  and  the  one  dimensional 
encoding  scheme  defined  in  CCITT  Recommendation  T.4; 

'tiled  T4  two  dimensional  encoding',  according  to  the 
tiling  scheme  defined  herein  and  the  two  dimensional 
encoding  scheme  defined  in  CCITT  Recommendation  T.4; 

'tiled  bitmap  encoding',  according  to  the  tiling 
scheme  defined  in  this  standard  and  the  bitmap  encoding 
scheme ; 

'tiled  T4 , T6  or  bitmap  encoding'  according  to  the 
tiling  scheme  defined  herein,  the  bitmap  encoding 
scheme,  the  two  dimensional  encoding  scheme  defined  in 
CCITT  Recommendation  T.6,  or  the  one  or  two  dimensional 
encoding  scheme  defined  in  CCITT  Recommendation  T.4. 

Add  the  following  paragraphs  after  the  line  beginning  "An 
explanation  of  these  coding  schemes  ..."  in  clause  7.1.1 
(Type  of  coding)  of  ISO  8613-7. 

The  value  'tiled  T6  encoding'  indicates  that  all  tiles  in  the 
content  portion  are  encoded  per  the  two  dimensional  encoding 
scheme  defined  in  CCITT  Recommendation  T.6. 

The  value  'tiled  T4  one  dimensional  encoding'  indicates  that 
all  tiles  in  the  content  portion  are  encoded  per  the  one 
dimensional  encoding  scheme  defined  in  CCITT  Recommendation 

T.4. 
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The  value  'tiled  T4  two  dimensional  encoding'  indicates  that 
all  tiles  in  the  content  portion  are  encoded  per  the  two 
dimensional  encoding  scheme  defined  in  CCITT  Recommendation 

T.4  . 

The  value  'tiled  bitmap  encoding'  indicates  that  all  tiles  in 
the  content  portion  are  encoded  per  the  bitmap  encoding 
scheme  defined  in  ISO  8613-7. 

The  value  'tiled  T4 , T6  or  bitmap  encoding'  indicates  that 
the  tiles  in  the  content  portion  are  each  encoded  per  the 
value  of  the  associated  "tile  types"  attribute  as  defined  in 

7.2.8. 

Add  the  following  paragraph  to  the  REMARKS  of  clause  7.1.1 
(Type  of  coding)  of  ISO  8613-7. 

For  bitmap  and  untiled  and  tiled  T.4  and  T.6  encoding  the 
relationship  between  the  order  of  pels,  the  order  of  encoded 
bits  within  an  oi?tet  and  the  order  of  encoded  octets  shall  be 
consistent  with  the  pel  array  order  specified  in  the  document 
profile. 

Add  the  following  line  to  clause  7.2.1  (Compression)  of  ISO 
8613-7. 


This  attribute  is  also  applicable  if  the  value  of  the 
attribute  "type  of  coding"  is  'tiled  T6  encoding',  'tiled  T4 
one  dimensional  encoding',  'tiled  T4  two  dimensional 
encoding'  or  'tiled  T4 , T6  or  bitmap  encoding'. 

Add  the  following  four  clauses  after  clause  7.2.4  (Number  of 
discarded  pels)  of  ISO  8613-7. 

7.2.5  Number  of  lines  per  tile 


CLASSIFICATION: 

APPLICABILITY: 

PERMISSIBLE  VALUE: 
DEFAULT  VALUE: 


Defaultable 

Formatted  processable  content 
architecture  class 

Positive  integer 

512 


DEFINITION: 

This  attribute  specifies  the  tile  dimension  in  units  of  "line 
spaces"  in  the  direction  of  line  progression. 
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REMARKS : 


This  attribute  is  only  applicable  if  the  value  of  the 
attribute  "type  of  coding"  is  'tiled  T6  encoding',  'tiled  T4 
one  dimensional  encoding',  'tiled  T4  two  dimensional 
encoding'  or  'tiled  T4 , T6  or  bitmap  encoding'. 

7.2.6  Number  of  pels  per  tile  line 


CLASSIFICATION: 

APPLICABILITY: 

PERMISSIBLE  VALUE: 
DEFAULT  VALUE: 


Defaultable 

Formatted  processable  content 
architecture  class 

Positive  integer 

512 


DEFINITION: 

This  attribute  specifies  the  tile  dimension  in  units  of  "pel 
spaces"  in  the  pel  path  direction. 

REMARKS : 

This  attribute  is  only  applicable  if  the  value  of  the 
attribute  "type  of  coding"  is  'tiled  T6  encoding',  'tiled  T4 
one  dimensional  encoding',  'tiled  T4  two  dimensional 
encoding'  or  'tiled  T4 , T6  or  bitmap  encoding'. 

7.2.7  Tiling  Offset 

CLASSIFICATION:  Defaultable 

APPLICABILITY:  Foirmatted  processable  content 

architecture  class 

STRUCTURE:  Coordinate  pair:  X coordinate, 

Y coordinate, 

PERMISSIBLE  VALUES:  Coordinate  pair:  non-negative  integer 

less  than  'number  of 
pels  per  tile  line', 
non-negative  integer 
less  than  'number 
lines  per  tile ' , 


DEFAULT  VALUE:  (0,0) 
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DEFINITION: 


This  attribute  specifies  the  location  of  the  pel  array  within 

the  tile  space  by  defining  the  offset  of  the  first  pel  of  the 

pel  array  from  the  first  pel  position  of  the  first  tile.  The 

offset  is  specified  in  pel  spaces  in  the  direction  of  the  pel 

path  and  line  spaces  in  the  direction  of  the  line 
progression . 

REMARKS : 

All  tiles  cover  a portion  of  the  pel  array.  Portions  of  the 
tile  space  outside  the  pel  array  are  artifacts  of  tiling  and 
contain  no  information. 


This  attribute  is  only  applicable  if  the  value  of  the 
attribute  "type  of  coding"  is  'tiled  T6  encoding',  'tiled  T4 
one  dimensional  encoding',  'tiled  T4  two  dimensional 
encoding'  or  'tiled  T4 , T6  or  bitmap  encoding'. 


7.2.8  Tile  types 
CLASSIFICATION: 


Defaultable 


APPLICABILITY: 


Formatted  processable  content 
architecture  class 


PERMISSIBLE  VALUES: 


'null  background',  'null  foreground', 
'bitmap  encoded',  'T6  encoded',  'T4  one 
dimensional  encoded',  'T4  two  dimensional 
encoded ' 


DEFAULT  VALUE: 


All  tiles  have  content  and  are  encoded 
according  to  the  value  of  the  attribute 
"type  of  coding" . 


DEFINITION: 


This  attribute  indicates  the  types  of  coding  of  tiles  in  the 
content  portion.  The  value  of  this  attribute  is  a sequence 
of  integers.  Each  integer  specifies  the  type  of  coding  of 
the  corresponding  tile  in  the  content  portion.  The  possible 
values  of  each  integer  are: 

'null  background',  indicating  that  all  pels  in  the 
tile  are  known  to  be  background  and  the  tile  has  no 
encoded  content, 

'null  foreground',  indicating  that  all  pels  in  the 
tile  are  known  to  be  foreground  and  the  tile  has  no 
encoded  content. 
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»T6  encoded',  indicating  that  the  pels  in  the  tile 
are  encoded  as  a T.6  primitive  octet  string, 

'T4  one  dimensional  encoded',  indicating  that  the 
pels  in  the  tile  are  encoded  as  a T.4  one  dimensional 
primitive  octet  string, 

'T4  two  dimensional  encoded',  indicating  that  the 
pels  in  the  tile  are  encoded  as  a T.4  two  dimensional 
primitive  octet  string, 

'bitmap  encoded',  indicating  that  the  pels  in  the 
tile  are  encoded  as  a bitmap  primitive  octet  string. 

REMARKS : 

If  the  attribute  "tile  types"  takes  its  default  value,  then 
there  are  no  null  tiles  and  all  tiles  are  encoded  as  either 
T.6,  T.4  one  dimensional,  T.4  two  dimensional  or  bitmap 
according  to  the  value  of  the  attribute  "type  of  coding." 

This  attribute  is  only  applicable  if  the  value  of  the 
attribute  "type  of  coding"  is  'tiled  T6  encoding',  'tiled  T4 
one  dimensional  encoding',  'tiled  T4  two  dimensional 
encoding'  or  'tiled  T4 , T6  or  bitmap  encoding'. 

Add  the  following  to  clause  7.3.1  (Content  information)  of 
ISO  8613-7. 

Tiled  raster  graphics  content  information  is  a sequence  of 
octet  strings  representing  those  portions  of  the  pel  array 
contained  by  non-null  tiles.  The  sequence  of  tiles  is 
ordered  in  the  direction  of  the  pel  path  and  line  progression 
as  illustrated  in  Figure  7.1 
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Figure  7.1  Tile  Attribute  and  Content  Ordering 


The  coding  attributes  describe  the  type  of  coding  for  each 
tile.  The  octet  string  describing  the  content  portion  of  the 
tile  may  be  T.4,  T.6,  bitmap  or  may  be  absent.  If  a null 
coding  is  specified  then  no  content  is  associated  with  the 
tile . 

Add  the  following  to  the  list  of  EXPORTS  in  clause  8.3 
(Representation  of  coding  attributes)  of  ISO  8613-7. 

Tile-type ; 

IMPORTS  Measure-Pair 
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Add  the  following  to  "Raster-Gr-Coding-Attributes”  in  clause 
8.3  (Representation  of  coding  attributes)  of  ISO  8613-7. 


number-of-pels-per-tile-line 

number-of-lines-per-tile 

tiling-offset 

tile-types 


[4]  IMPLICIT  INTEGER 

OPTIONAL, 

[5]  IMPLICIT  INTEGER 

OPTIONAL, 

[6]  IMPLICIT  Measure-Pair 

OPTIONAL, 

[7]  IMPLICIT  SEQUENCE  OF 

Tile-type  OPTIONAL  } 


Add  the  following  after  the  "Compression"  definition  in 
clause  8.3  (Representation  of  coding  attributes)  of  ISO 
8613-7. 


Tile-type  ::=  INTEGER  { 

null  background (0) , 
null  foreground ( 1) , 

T. 6 encoded (2) , 

T.4  one  dimensional  encoded (3), 
T.4  two  dimensional  encoded (4), 
bitmap  encoded (5)  } 

Add  the  following  after  "pel  array"  in  the  first  line  of 
clause  9 (Coding  schemes)  of  ISO  8613-7. 

or  tile 


Add  the  following  to  Table  6 in  clause  12  (Definition  of 
raster  graphics  content  architecture  classes)  of  ISO  8613-7. 


Number  of  pels  per  t'line 

- 

Number  of  lines  per  tile 

- 

D^) 

Tiling  offset 

- 

D^) 

Tile  types 

— 

D^) 

NOTE  3-This  attribute  is  only  applicable  if  the  value 
of  the  attribute  "type  of  coding"  is  tiled  encoding. 
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Add  the  following  to  clause  A. 2. 2 of  the  Annexes  of  ISO 
8613-7. 


[Type  of 
coding] 

Tiled  T6  encoding 

Tiled  T4  one  dimensional  encoding 
Tiled  T4  two  dimensional  encoding 
Tiled  bitmap  encoding 
Tiled  T4/T6/bitmap  encoding 


Number  of  pels  Any  non-negative  integer  512 

per  tile  line 


Number  of  lines  Any  non-negative  integer  512 

per  tile 


Tiling  offset 

Coordinate  Pair  (Any  non-negative  integer,  (0,0) 

less  than  'number  of  pels 
per  tile  line ' , 

Any  non-negative  integer 
less  than  'number  of 
lines  per  tile ' ) 


Tile  types 


sequence  of  positive  According  to  the 

integers  value  of  the 

attribute  "type 
of  coding". 


NOTE  2 - The  attribute  "compression"  is  also  applicable 
if  the  value  of  the  attribute  "type  of  coding"  is  'tiled 
T6  encoding',  'tiled  T4  two  dimensional  encoding', 

'tiled  T4  one  dimensional  encoding'  or  'tiled  T4 , T6  or 
bitmap  encoding'. 


Add  the  following  to  the  item  list  in  Annex  B of  ISO  8613-7. 

RP-2  is  an  example  of  a content  architecture  level 
belonging  to  the  formatted  processable  content 
architecture  class  utilizing  tiling.  Content  pertaining 
to  this  level  may  be  laid  out  using  the  fixed  dimension 
layout  method. 
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Add  the  following  to  the  end  of  Annex  B of  ISO  8613-7. 

B.5  Raster  graphics  content  architecture  level  RP-2 

RP-2  is  a raster  graphics  content  architecture  level  derived 
from  the  formatted  processable  content  architecture  class 
utilizing  tiling;  it  is  laid  out  using  the  fixed  dimension 
method  of  the  processable  content  layout  process. 

B.5.1  Presentation  attributes 


ATTRIBUTE 

BASIC  VALUES  NON-BASIC 

VALUES 

DEFAULT 

VALUE 

Pel  path 

0,  90,  180,  None 

270  deg 

Standard 
Default  Value 

Line  progression-.. 

90,  270  deg  None 

Standard 
Default  Value 

Pel  spacing 

(Any  positive  None 

integer,  any 
positive  integer) 

SMU 

Standard 
Default  Value 

Spacing  ratio 

(Any  positive  None 

integer,  any 
positive  integer) 

Standard 
Default  Value 

Clipping 

None 

Standard 

First  pair 

Second  pair 

(Any  non-negative 
integer,  any  non- 
negative integer) 

(Any  non-negative 
integer,  any  non- 
negative integer) 

Default  Value 
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B.5.2  Content  portion  attributes 


ATTRIBUTE 

BASIC  VALUES 

NON -BASIC 

VALUES 

DEFAULT 

VALUE 

Number  of  pels 
per  line 

Any  positive 
integer 

None 

None 

Number  of 
lines 

Any  positive 
integer 

None 

None 

Type  of 
coding 

tiled  T4,  T6 
or  bitmap 
encoding 

tiled  T6  encoding 
tiled  T4  encoding 
( one-dimensional ) 
tiled  T4  encoding 
(two-dimensional) 

Standard 

Default 

Value 

Compression 
see  note  1 

Compressed 
as  in  T.6 

Uncompressed 
as  in  T.6 

Standard 

Default 

Value 

Number  of  pels 
per  tile  line 

Any  non-negative 
integer 

None 

Standard 

Default 

Value 

Number  of 
lines  per  tile 

Any  non-negative 
integer 

None 

Standard 

Default 

Value 

Tiling  offset 

(Any  non-negative 
integer,  any  non- 
negative integer) 

None 

Standard 

Default 

Value 

Tile  types 

sequence  of 

positive 

integers 

None 

Standard 

Default 

Value 

NOTE  1 - The  attribute  "compression"  is  only  applicable  if 
the  value  of  the  attribute  "type  of  coding"  is  'tiled  T6 
encoding',  'tiled  T4  two  dimensional  encoding',  'tiled  T4 
one  dimensional  encoding'  or  'tiled  T4 , T6  or  bitmap 
encoding ' . 
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